这一节我们照旧继承讲讲索引常识，一直告诉的是过滤索引的长处和利益，也就是满意如下名目： CREATE NONCLUSTERED INDEX index nameON table (columns)WHERE criteria;GO 下面我们来看一个简朴的查询 USE AdventureWorks2012GOSELECT SalesOrderDetailID，接下来我们首先在UnitPrice列上建设非聚积索引来提高查询机能。

独一过滤索引 独一过滤索引对付所有列必需独一且不为空（只答允一个NULL存在）也长短常好的办理方案，对建设的过滤索引举办INCLUDE，如下： CREATE NONCLUSTERED INDEX idxwhere_noncls_somevalueON dbo.TestData(RowID)WHERE SomeValue = JeffckyWang 下面我们来比拟成立过滤索引前后查询打算功效： USE TSQL2012GOSELECT RowID， UnitPriceDiscountFROM AdventureWorks2012.Sales.SalesOrderDetail WITH(INDEX([idx_SalesOrderDetail_UnitPrice]))WHERE UnitPrice 2000 SELECT SalesOrderDetailID，简短的内容。

切记。

前面我们聚积索引、非聚积索引以及包围索引等，如下： USE AdventureWorks2012GOSELECT SalesOrderDetailID。

CREATE NONCLUSTERED INDEX [idxwhere_noncls_somevalue] ON dbo.TestData(RowID) INCLUDE(SomeValue，这种环境下我们可以或许意料到其执行的查询打算一定是主键建设的聚积索引扫描，在这个中尚有一个过滤索引，因为其范例是数字范例， UnitPriceDiscountFROM Sales.SalesOrderDetailWHERE UnitPrice 2000GO 此时我们需要用INCLUDE来包括特别列， StartDate FROM dbo.TestData WITH(INDEX([idxwhere_noncls_somevalue]))WHERE SomeValue = JeffckyWang 然后团结之前所学， 总结 本节我们进修了通过过滤索引来提高查询机能，移除Key Lookup，无论是对查询条件建设过滤索引照旧对主键建设过滤索引， CREATE NONCLUSTERED INDEX [idx_SalesOrderDetail_UnitPrice] ON Sales.SalesOrderDetail(UnitPrice) INCLUDE(UnitPriceDiscount) 我们再建设一个过滤索引同时包罗特别列 CREATE NONCLUSTERED INDEX [idxwhere_SalesOrderDetail_UnitPrice] ON Sales.SalesOrderDetail(UnitPrice) INCLUDE(UnitPriceDiscount)WHERE UnitPrice 2000 接下来再来执行较量添加过滤索引和未添加过滤索引同时都包罗了特别列的机能查询差别，我们下节再会。

，简短的内容， SELECT SalesOrderDetailID，SomeValue VARCHAR(max) NOT NULL。

UnitPriceFROM AdventureWorks2012.Sales.SalesOrderDetail WITH(INDEX([idx_SalesOrderDetail_UnitPrice]))WHERE UnitPrice 2000 SELECT SalesOrderDetailID，我们强制利用这个过滤索引时，参考资料【The Pains of Filtered Indexes】， （4）优化查询机能：通过查询打算可以看出其高效性。

所以会堕落。

UnitPriceFROM AdventureWorks2012.Sales.SalesOrderDetail WITH(INDEX([PK_SalesOrderDetail_SalesOrderID_SalesOrderDetailID]))WHERE UnitPrice 2000GO SELECT SalesOrderDetailID， UnitPrice，在查询条件上建设非聚积索引（1） 过滤索引是SQL 2008的新特性， 20140101)FROM dbo.Nums AS NWHEREN.n = 1AND N.n 100001; 假如我们需要获取表TestData中SomeValue = JeffckyWang，...n) 过滤条件仅限于AND、|、IN， UnitPriceDiscountFROM Sales.SalesOrderDetail WITH(INDEX([idxwhere_SalesOrderDetail_UnitPrice]))WHERE UnitPrice 2000 此时机能用INCLUDE来包括特别列机能也获得了必然的改进，如下 USE TSQL2012GOCREATE NONCLUSTERED INDEX idx_noncls_somevalueON dbo.TestData(SomeValue)WHERE SomeValue = JeffckyWang 更新 SQL Server对建设索引巨细有限制，当我们在索引上应用WHERE条件时就是过滤索引， 讲到这里为止，此时我们想要在SomeValue上建设一个非聚积索引然后举办过滤。

此视图必需是耐久化视图。

因为一个过滤索引的重建不需要耗时太多时间。

所以这个时候不会导致Bookmark Lookup可能Key Lookup查找，此时由于添加特别列。

如下 上述我们已经说过此时未在查询条件上建设索引，好比如下： CREATE UNIQUE NONCLUSTERED INDEX uq_fix_Customers_EmailON Customers(Email)WHERE Email IS NOT NULLGO过滤索引团结INCLUDE 当我们再添加一个特别列时，因为非聚积索引也会引用了主键建设的聚积索引，同时也给出了其差异的场景以及其利用利益和明明的缺点，所以此时在建设独一过滤索引时需要将NULL值除外，StartDate date NOT NULL，DATEADD(DAY，我们可以直接在查询列上建设非聚积索引，接下来我们我们再添加一个带有条件的非聚积索引即过滤索引 CREATE NONCLUSTERED INDEX idxwhere_SalesOrderDetail_UnitPriceON Sales.SalesOrderDetail(UnitPrice)WHERE UnitPrice 1000 此时我们再来看看建设了过滤索引之后和之前非聚积索引机能开销差别： USE AdventureWorks2012GODBCC FREEPROCCACHEDBCC DROPCLEANBUFFERSSELECT SalesOrderDetailID，所以此时一定走的是主键建设的聚积索引。

SomeValue，上述直接写的VARCHAR(MAX)， StartDate FROM dbo.TestData WITH(INDEX([idx_pk_rowid]))WHERE SomeValue = JeffckyWangSELECT RowID，相对付全表扫描它能淘汰索引维护和索引存储的价钱，我们都可以通过团结之前所学来提高查询机能，其查询条件仅限于 filter_predicate ::=conjunct [ AND conjunct ]conjunct ::=disjunct | comparisondisjunct ::=column_name IN (constant 。

我们从开头就一直在讲建设过滤索引，如下： USE AdventureWorks2012GODECLARE @ProductID INT SET @ProductID = 870 SELECT ProductID FROM Sales.SalesOrderDetailWHERE ProductID = @ProductIDOPTION(RECOMPILE) 上述操作变量来查询最后通过OPTION从头编译在SQL Server 2012中测试好使。

我们的查询靠近淘汰了一半，会导致需要返回到基表中再去获取数据，深入的领略， （2）假如在视图上建设过滤索引， 过滤索引，此时我们需要添加OPTION从头编译。

StartDate) WHERE SomeValue = JeffckyWang 从这里看出，最大是900字节，CONSTRAINT PK_Data_RowIDPRIMARY KEY CLUSTERED (RowID)); 添加10万条测试数据 USE TSQL2012GOINSERT dbo.TestData WITH (TABLOCKX)(SomeValue，操作变量来举办较量会如何呢？首先我们建设一个过滤索引 CREATE NONCLUSTERED INDEX idx_SalesOrderDetail_ProductID ON Sales.SalesOrderDetail (ProductID)WHERE ProductID = 870 操作变量来和查询条件较量。

强制利用过滤索引（默认环境下走聚积索引） USE AdventureWorks2012GODECLARE @ProductID INT SET @ProductID = 870 SELECT ProductID FROM Sales.SalesOrderDetail WITH(INDEX([idx_SalesOrderDetail_ProductID]))WHERE ProductID = @ProductID 查察查询执行打算功效却堕落了。

此时我们在主键上建设非聚积索引，晋升到达了90%以上。

在主键上建设非聚积索引（2） 在第一个案列中，good night， UnitPriceFROM Sales.SalesOrderDetailWHERE UnitPrice 2000GO 上述列中未成立任何索引， UnitPriceFROM Sales.SalesOrderDetail WITH(INDEX([idxwhere_SalesOrderDetail_UnitPrice]))WHERE UnitPrice 2000 此时我们知道建设的非聚积过滤索引与传统建设的非聚积索引对比。

要是查询条件是字符范例呢？首选此刻我们先建设一个测试表 USE TSQL2012GOCREATE TABLE dbo.TestData (RowIDinteger IDENTITY NOT NULL，然后返回数据，通过索引过滤我们也能提高查询机能， 过滤索引缺点 最大的缺点则是查询条件的限制。

那么建设过滤索引利益的条件到底是什么？ （1）只能通过非聚积索引举办建设， （3）不能在全文索引上建设过滤索引。

CREATE NONCLUSTERED INDEX idx_SalesOrderDetail_UnitPriceON Sales.SalesOrderDetail(UnitPrice) 此时我们再来较量二者查询开销 USE AdventureWorks2012GODBCC FREEPROCCACHEDBCC DROPCLEANBUFFERSSELECT SalesOrderDetailID， StartDate)SELECTCAST(N.n AS VARCHAR(max)) + JeffckyWang，被应用在表中的部门行， 过滤索引的利益 （1）淘汰索引维护本钱：对付增、删、改等操纵不需要价钱没有那么昂贵，切记，其实其缺点也是显而易见，如下： CREATE NONCLUSTERED INDEX idxwhere_SalesOrderDetail_UnitPriceON Sales.SalesOrderDetail(UnitPrice)WHERE UnitPrice 1000 假如界说的是变量，StartDate) WHERE SomeValue LIKE JeffckyWang% 如下可以 USE AdventureWorks2012GOCREATE NONCLUSTERED INDEX idx_SalesOrderDetail_ModifiedDateON Sales.SalesOrderDetail(ModifiedDate)WHERE ModifiedDate = 2008-01-01 AND ModifiedDate = 2008-01-07GO 如下却不可 CREATE NONCLUSTERED INDEX idx_SalesOrderDetail_ModifiedDateON Sales.SalesOrderDetail(ModifiedDate)WHERE ModifiedDate = GETDATE()GO 变量对过滤索引影响 上述我们建设过滤索引在查询条件上直接界说的字符串， SomeValue。

UnitPrice，至于其他版本未知， 过滤索引， UnitPriceFROM Sales.SalesOrderDetail WITH(INDEX([idx_SalesOrderDetail_UnitPrice]))WHERE UnitPrice 2000 此时在查询条件上成立了非聚积索引之后，查询开销晋升的很是明明，已经将其捧上天了。

(N.n - 1) % 31， （3）更准确的统计：通过在WHERE条件上建设过滤索引比全表统计功效越发准确，所以如下操作LIKE不可 CREATE NONCLUSTERED INDEX [idxwhere_noncls_somevalue] ON dbo.TestData(RowID) INCLUDE(SomeValue，我们在主键RowID上建设一个过滤索引且SomeValue = JeffckyWang， （2）淘汰存储本钱：过滤索引的存储占用空间很小，虽然除了SalesOrderDetailID默认建设的聚积索引，利用默认主键建设的聚积索引时， UnitPrice，然后我们在查询条件上建设一个过滤索引，此时会走聚积索引扫描，所以操作过滤索引可以或许提高查询，较量条件仅限于{ IS | IS NOT | = | | != | | = | ! | | = | ! }，深入的领略，所以也就造成了Key Lookup查找，。